modules/cart/presentation/components/add-to-cart-button.tsx (1)

86-91: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Lógica de "¿tiene contenido de personalización?" duplicada en 3 lugares.

La misma fórmula (hasText(text) || hasText(color) || hasText(size) || hasText(imageUrl) || Boolean(designPosition)) se repite en isAuthCustomizationMatching, en el cálculo de isCustomizationHasContent a nivel de componente, y dentro de performAuthenticatedAdd. Extraer un helper único reduciría el riesgo de que las tres copias diverjan si cambia el criterio.

♻️ Refactor propuesto: helper compartido

 const hasText = (value?: string | null) => value != null && value.length > 0;
+
+function hasCustomizationContent(
+  draft: {
+    text?: string | null;
+    color?: string | null;
+    size?: string | null;
+    imageUrl?: string | null;
+    designPosition?: unknown;
+  } | null,
+): boolean {
+  if (!draft) return false;
+  return (
+    hasText(draft.text) ||
+    hasText(draft.color) ||
+    hasText(draft.size) ||
+    hasText(draft.imageUrl) ||
+    Boolean(draft.designPosition)
+  );
+}

Y reutilizarlo en los tres puntos (isAuthCustomizationMatching, isCustomizationHasContent, performAuthenticatedAdd).

Also applies to: 152-157, 354-360

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@modules/cart/presentation/components/add-to-cart-button.tsx` around lines 86
- 91, The “has customization content” check is duplicated in
add-to-cart-button.tsx across isAuthCustomizationMatching, the
isCustomizationHasContent component calculation, and performAuthenticatedAdd.
Extract that shared logic into a single helper in this component/module (using
the existing hasText, norm.text, norm.color, norm.size, norm.imageUrl, and
norm.designPosition fields) and reuse it in all three places so the criterion
stays consistent.

shared/presentation/lib/to-absolute-url.ts (1)

6-10: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Inconsistencia menor entre window y globalThis.

Se comprueba typeof window === 'undefined' pero luego se usa globalThis.location.origin. Funcionalmente equivalente en el navegador, pero sería más consistente usar globalThis en ambos puntos (o window en ambos).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@shared/presentation/lib/to-absolute-url.ts` around lines 6 - 10, The
`toAbsoluteUrl` helper mixes `window` and `globalThis` for the environment check
and URL resolution, which is inconsistent. Update the logic in `toAbsoluteUrl`
to use the same global reference throughout the function, either by checking
`globalThis` instead of `window` or by using `window` for both the guard and
`location.origin` access.

app/[locale]/products/[id]/customization-form.tsx (1)

60-65: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Inconsistencia de estilo entre campos text y size.

El campo size ahora usa errors.size == null mientras que text sigue usando comprobación truthy (errors.text ? ..., líneas 62, 81 y 86, sin cambios). No es un bug pero sería más consistente aplicar el mismo criterio a ambos campos.

Also applies to: 137-137, 147-147

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/`[locale]/products/[id]/customization-form.tsx around lines 60 - 65, The
error ID checks in customization-form.tsx are inconsistent between the text and
size fields; update the remaining text-related logic in CustomizationForm to use
the same null/undefined check pattern as size. Specifically, align the
conditional used for textErrorId and any related text field error handling with
the errors.size == null approach so the form uses a consistent convention across
both fields.

app/[locale]/auth/verify-email/page.tsx (1)

25-44: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Considerar ignorar AbortError en el catch.

Si token cambiara y el efecto se reejecutara, el catch de la petición abortada anterior también llamaría a setStatus('invalid'), pudiendo pisar el estado correcto de la nueva petición en curso. Es un caso de baja probabilidad (token normalmente fijo), pero fácil de blindar comprobando controller.signal.aborted antes de actualizar el estado.

🛡️ Fix sugerido

       } catch {
-        setStatus('invalid');
+      } catch {
+        if (!controller.signal.aborted) {
+          setStatus('invalid');
+        }
       }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/`[locale]/auth/verify-email/page.tsx around lines 25 - 44, The
verify-email request handler in the async effect can wrongly set status to
invalid after an aborted fetch when the token changes. Update the try/catch flow
in the verify-email page component so the catch block checks the AbortController
state (for example via controller.signal.aborted) and skips setStatus on aborted
requests, only mapping real failures to invalid. Keep the behavior aligned with
the existing success/expired/invalid logic in the effect that calls fetch and
setStatus.

composition-root/container.ts (1)

105-105: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoff

Tipado débil: Record<string, unknown> para el estado central del contenedor.

Cada getter/setter requiere castear (as X) el valor almacenado en state, perdiendo la verificación en tiempo de compilación que ofrecían las variables individuales tipadas previas. Un typo en la clave (state.emailSedner en vez de state.emailSender, por ejemplo) no sería detectado hasta ejecución.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@composition-root/container.ts` at line 105, El estado central del contenedor
está tipado demasiado débilmente con Record<string, unknown>, lo que obliga a
castings en cada acceso y elimina la verificación de claves y tipos. Refactoriza
el objeto state en composition-root/container.ts para usar un tipo explícito con
propiedades nombradas para cada servicio/configuración, y actualiza los
getters/setters relacionados para leer y escribir con ese tipo en lugar de
depender de as X, usando los símbolos state y los accesores del contenedor para
ubicar los cambios.

shared/kernel/container.ts (1)

24-24: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoff

Tipado débil: state: Record<string, unknown> reemplaza variables tipadas.

El uso de Record<string, unknown> con casts as EmailSender en cada getter/setter renuncia a la seguridad de tipos que ofrecían las variables let tipadas previas. Un error de clave (typo) no sería detectado en tiempo de compilación.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@shared/kernel/container.ts` at line 24, The `state: Record<string, unknown>`
map in `container.ts` weakens type safety and forces `as EmailSender` casts in
the related getters/setters. Replace the untyped bag with explicit typed storage
for each dependency or a strongly typed container interface, and update the
accessor functions to read/write through those typed symbols so typos in keys
are caught at compile time.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes